Early software programs in areas such as inventory control, human resources, sales automation, and database management were designed to run independently, with no interaction between the programs. The programs were custom built in the technology of the day for a specific need being addressed and were often proprietary systems. As enterprises grew and recognized the need for their information and applications to have the ability to be transferred across and shared between systems, companies began investing in enterprise application integration (EAI) systems in order to streamline processes and keep all the elements of the enterprise interconnected.
Some EAI systems include an integrated development environment (IDE; also known as “integrated design environment” and “integrated debugging environment”). An IDE is a type of computer software that assists computer programmers in developing integrated software applications. IDEs typically consist of a source code editor, a compiler and/or interpreter, build-automation tools, and (usually) a debugger. Sometimes a version control system (VCS) and various tools to simplify the construction of a GUI are integrated as well. Although some multiple-language IDEs are in use, such as the Eclipse IDE, NetBeans, and Microsoft Visual Studio, an IDE is typically devoted to a specific programming language, as in the Visual Basic IDE.
Today, many EAI systems contain their own VCS. However, many enterprises that purchase EAI systems prefer to continue to use their existing third party VCS rather than the embedded VCS of their respective EAI system. Common third party VCSs include Concurrent Versions System (CVS), Source Code Control System (SCCS), and Clear Case. Such enterprises typically configure an IDE client to interact directly with the third party VCS. In order to use a third party VCS, an integration project is saved locally as components (e.g., files) and the components are then checked into the third party VCS. A plug-in (i.e., an API) is used to allow the IDE client to interact with the third party VCS.
FIG. 1 is a block diagram illustrating this approach for enabling an IDE client 102 to interact with a third party VCS. IDE client 102 interacts with a VCS through a version control API 104. The API 104 is implemented by an API implementation 106.
The system of FIG. 1 may operate as follows. A source file for a coding project is created and stored locally on IDE client 102. A user (e.g., through a GUI of IDE 102) initiates a check-in operation, whereby IDE 102 invokes the VCS API 104, which causes the API implementation 106 to be executed. In turn, the API implementation 106 invokes the check-in function of the VCS 110, which causes the source file to be stored in data storage 112.
A disadvantage of the above approach is the significant risk of losing work if a user does not take the steps necessary to check in modified files to a VCS. For example, if a user forgets to check in modified files, then all the changes may be lost when the user logs out of the system. Therefore, there is a need to provide a better mechanism for enabling a third party VCS to be used in an EAI system.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.